“Never Trust, Always Verify”: Zero Trust on AWS, When Security Is a Must
It is the contemporary era, the post-pandemic era, the one that has enticed companies to migrate more and more towards “Cloud oriented” business models to take advantage of all the advantages of scalability, efficiency, cost reductionand above all security. Suffice it to say that in 2020, external attacks on Cloud accounts increased by 630%. And theincreasing use of remote work expands the traditional attack perimeter and threat landscape.
Zero Trust Security
Securing the corporate network is no longer enough. An area must be delineated through the implementation of identity solutions to provide the right access to IT people and devices, optimizing controls based on the risk profiles of the entities accessing various resources. Zero Trust is just that, a security model centered on the idea that data shouldn’t be accessed solely based on network location. It requires users and systems to prove their identity and trustworthiness, and enforces “fine-grained” identity-based authorization rules before allowing them to access applications, data, and other systems. In essence, the zero-trust model is based on the principle of “never trust, always verify“.
Traditional security models, in fact, aim to enclose an organization within a perimeter designed to block threats that come from the outside. This is a seemingly reasonable concept, except for the fact that all threats come from outside and that administrators must necessarily trust people and devices within the network. It is therefore based on the assumption that no user in the organization has been compromised previously and that they always act in good faith and in a reliable manner. Clearly today this is no longer the case since the perimeters of an organization have melted like snow in the sun from the use of smart working. And for the increasing number of personal devices, from smartphones to notebooks that are used for work.
In essence, zero-trust security has replaced the old assumptions that resources within the perimeter of the corporate network must be trusted, and considers trust as a vulnerability, since users of a “trusted” network could move within the network or cause the takeover of all data to which they legitimately had access.
But what happens in AWS?
The mission at
Amazon Web Services
is, as is now known, to innovate on behalf of customers so that they have less and less work to do when building, deploying, and rapidly iterating on secure systems. From a security perspective, customers are looking for answers to a question: What are the optimal models to ensure the right level of confidentiality, integrity and availability of systems and data, while increasing speed and agility? The most obvious example of Zero Trust on AWS is how millions of customers typically interact with AWS every day using the management console or securely calling AWS APIs over a diverse set of public and private networks.
Whether they are called through the console, the AWS Command Line Interface (AWS CLI), or software written in AWS APIs, ultimately all of these interaction methods reach a set of web services with endpoints that are reachable from the internet. There is absolutely nothing about the security of the AWS API infrastructure that depends on the reachability of the network. Each of these signed API requests is authenticated and authorized each time at a rate of millions and millions of requests per second globally. Customers, therefore, do it safely; knowing that the cryptographic strength of the underlying Transport Layer Security (TLS) protocol, enhanced by the AWS Signature v4 signing process, adequately protects these requests without any regard for the reliability of the underlying network. Interestingly, the use of cloud-based APIs is rarely mentioned in Zero Trust discussions. Perhaps this is because AWS has led the way with this approach to API protection from the beginning, so much so that it is now assumed to be a critical part of every cloud security story.